Architecture Design

decorative image showing notional development of project using geometric shapes

Overview

The Architecture Design process is a trade and synthesis method to allow the Program Manager (PM) and Systems Engineer to translate the outputs of the Stakeholder Requirements Definition and Requirements Analysis processes into alternative design solutions and establishes the architectural design of candidate solutions that may be found in a system model. The alternative design solutions may include hardware, software and human elements; their enabling system elements; and related internal and external interfaces.

The Architecture Design process, combined with Stakeholder Requirements Definition and Requirements Analysis, provides key insights into technical risks early in the acquisition life cycle, allowing for early development of mitigation strategies. Architecture Design is integral to ensuring that multiple well-supported solutions are considered. The Architecture Design process supports analysis of design considerations and enables reasoning about key system aspects and attributes such as reliability, maintainability, survivability, sustainability, performance and total ownership cost.

Analyzing Alternatives

Architecture design synthesizes multiple potential solutions from system performance requirements, evaluates those solutions and eventually describes the system down to the individual system element for implementation. The Architecture Design process is iterative and strives to seek a balance among cost, schedule, performance, and risk that still meets stakeholder needs. The development of the system architecture should adhere to sound systems engineering (SE) and conform to industry standards as applicable. The functional architecture should be part of the functional baseline, and the physical architecture should be part of the allocated and product baselines.

image of computer connected to three servers with caption titled configuration control

The system architecture should be placed under configuration control and maintained in a robust repository that maintains the architecture descriptions and its relationships to each of the baselines. This control provides the Systems Engineer with a means of ensuring consistency of the system architecture definition throughout the acquisition life cycle.

Architecture Types

Functional Architecture

The functional architecture provides the foundation for defining the system architecture through the allocation of functions and sub-functions to hardware/software, databases, facilities and human operations to achieve its mission.

Physical Architecture

The physical architecture consists of one or more product structures, or views, of the physical solution. The development of the physical architecture is an iterative and recursive process and evolves together with the functional requirements and functional architecture. Development of the physical architecture is complete when the system has been decomposed to the lowest system element (usually the lowest replaceable unit of the support strategy). It is critical that this process identify the design drivers and driving requirements as early as possible.

Product Structure

The product structure may consist of conceptual design drawings, schematics and/or block diagrams that define the system’s form and the arrangement of the system elements and associated interfaces. The DoD Architecture Framework (DoDAF) provides guidance on how to generate operational and system views that describe interface relationships in a manner common across the DoD user community (see the DoD CIO DoDAF page for additional information).

Key Activities

The PM may oversee Architecture Design efforts to gain and maintain insights into program schedule and cost drivers for use in the evaluation of alternative architectures, excursions, mitigation approaches, etc.

Key activities in the Architecture Design process include:

During this process, derived requirements come from solution decisions. It is essential to identify derived requirements and ensure that they are traceable and part of the allocated requirements. For each given solution alternative, the Decision Analysis process trades off requirements against given solution alternatives. For each solution alternative, based on programmatic decisions, certain performance requirements may be emphasized over others. The essence of this activity is to achieve a balanced and feasible design with acceptable risk; that falls within the program design constraints.

An integral part of defining and refining the functional and physical architecture is to provide technical support to the market research, especially early in the acquisition life cycle. Systems engineers should analyze whether existing products (commercial or non-developmental items) can meet user performance requirements or whether technologies can realistically be matured within the required time frame. When possible, mature technologies should be used to satisfy end-user needs.

Key Outputs

The output of the architecture design process is the allocated baseline, which includes the documentation that describes the physical architecture of the system and the specifications that describe the functional and performance requirements for each configuration item, along with the interfaces that compose the system. In addition, Work Breakdown Structures (WBS) and other technical planning documentation are updated. The system architecture and the resulting design documentation should be sufficiently detailed to:

Confirmation of requirements traceability and the soundness of the selected physical architecture can be accomplished using a cost-effective combination of design modeling and analysis, as applicable.

The result of the Architecture Design process is an architectural design that meets the end-user capability needs shown in the Requirements Management process to have all stated and derived requirements allocated to lower-level system elements and to have the possibility of meeting cost, schedule and performance objectives. The architectural design should be able to be communicated to the customers and to the design engineers.

The level of detail of the architectural design depends on the complexity of the system and the support strategy. It should be detailed enough to bound the cost and schedule of the delivered system, define the interfaces, assure customers that the requirements can be met and control the design process down to the lowest removable unit to support operations and sustainment. This architecture design may be documented and found in a program’s system model. Once identified, the system architecture is placed under configuration management.

Products and Tasks

  1. Provide government participation, oversight, and support of the system requirements review to formalize initiation of the stakeholder requirements definition and requirements analysis processes.
  2. Review and approve contractor analysis and description of anticipated physical external interfaces.
  3. Review and approve contractor analysis of system constraint requirements (size, weight, cost, etc.)
  4. Synthesize potential solutions from system performance requirements.
  5. Evaluate cost and effectiveness of potential design solutions.
  6. Provide decision maker with reviewed and updated (if required) system performance spec for approval
  1. Identify the design considerations relevant to the system in accordance with the system concept of operations and capabilities requirement documents.
  2. Develop system functional, performance, and interface requirements to be included in the system performance specification that are traceable to the relevant design considerations.
  3. Develop functional decomposition of design consideration traceable requirements.
  4. Evaluate functional decomposition of design consideration traceable requirements provided by the system developer / contractor as applicable.
  5. Evaluate a system performance specification and system functional architecture for traceability to relevant design considerations and capability requirements documents.
  6. Provide design consideration inputs to the decision maker for inclusion in the system performance specification and functional architecture.
  1. Identify system requirements traceable to design considerations relevant to the system in accordance with the system concept of operations and capabilities requirement documents.
  2. Identify technical certifications associated with technical requirements derived from the relevant design considerations.
  3. Identify the required technical activities and data deliverables needed to address each design considerations.
  4. Recommend assignment of responsibility to each design consideration.
  5. Develop specific request for proposal or contract language to acquire the activities and data deliverables identified.
  6. Develop summary of technical activities, responsibilities and outputs, and provide for inclusion in the design considerations section of the systems engineering plan in accordance with current guidance.
  1. Identify each requirement derived from the relevant set of design considerations in accordance with system functional baseline documentation.
  2. Identify all hardware and software configuration items and the interfaces among those items and the external environment in accordance with the system physical architecture descriptions.
  3. Compare the system allocated baseline against the functional baseline to trace design consideration-related requirements.
  4. For discrepancies identified between the system allocated baseline and the functional baseline, recommend changes to the functional or allocated baselines to correct the discrepancies.
  1. Identify physical architecture design alternatives that satisfy the functional baseline (system performance specification) and functional architecture.
  2. Define the allocation of physical resources to functions defined in the functional architecture and the system performance specification for each alternative architecture.
  3. Analyze each physical architecture alternative for compliance with the functional baseline, and cost and schedule constraints.
  4. Document results of the design alternative analysis and provide analysis to decision maker.
  5. Recommend preferred physical architecture design to decision maker.
  6. Document the approved physical architecture with the appropriate diagrams, item performance specifications and interface specifications or the equivalent digital model.
  1. Support requirements analysis process activity.
  2. Review contractor analysis of any derived requirements.
  3. Review functional baseline.
  4. Review physical architecture.
  5. Review the allocation of system functions to elements of system architecture.
  6. Review system allocated baseline and recommend adjustments, if required.
  7. Approve the system allocated baseline.
  1. Identify design architecture requirements for the acquisition.
  2. Identify cyber-security and net-ready key performance parameter (NR-KPP) compliance requirements in accordance with current guidance.
  3. Apply DoD architecture framework (DoDAF) operational and system viewpoints to develop and describe the system key mission areas, functional architecture, design interfaces, interoperability standards and business processes in accordance with joint capability integration and development system (JCIDS).
  4. Verify that the mandatory architecture views comply DoD information enterprise architecture (IEA).
  5. Document all architecture views for the acquisition for inclusion in the systems engineering plan (SEP).

Source: AWQI eWorkbook

Resources

Key Terms

Source:
DAU Glossary
DAU ACQuipedia

Statutes, Regulations, Guidance

Media

DAU Training Courses

DAU Communities of Practice

On this page

  1. Overview
  2. Analyzing Alternatives
  3. Architecture Types
  4. Key Activities
  5. Key Outputs
  6. Resources
Back to top